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ABSTRACT 

The  NAVSTAR  Global  Positioning  System  (GPS)  allows 
extremely  accurate  and  global  determination  of  time,  as 
well  as  position  and  velocity.  An  STI  Time  Transfer  Unit 
(TTU)  developed  for  the  U.S.  Naval  Observatory  (USNO)  has 
consistently  demonstrated  the  transfer  of  time  with  accu¬ 
racies  much  better  than  100  nanoseconds.  A  new  STI  Time 
Transfer  System  (TTS),  the  T IS  502,  is  currently  in  devel¬ 
opment  and  will  be  available  on  the  market  by  the  end  of 
1981.  The  TTS  502  will  be  a  relatively  compact  micropro¬ 
cessor-based  system  with  a  variety  of  options  that  will 
meet  each  individual's  requirements,  and  will  have  the 
same  performance  as  the  USNO  system.  This  paper  summa¬ 
rizes  the  time  transfer  performance  of  that  USNO  system 
and  presents  the  details  of  the  new  system. 

INTRODUCTION  AND  SUMMARY 

The  NAVSTAR  GPS  is  currently  operating  in  its  Concept  Validation  Phase 
(Phase  I),  while  the  operational  system  is  under  development.  Rather 
than  being  repetitive  on  the  description  of  the  system,  which  has  been 
described  in  numerous  papers  over  the  last  6  years,  let  it  suffice  to 
refer  to  a  few  of  these  papers  in  References  1  through  3.  The  impor¬ 
tant  factor  to  note  here,  however,  is  that  even  though  the  system  is 
not  fully  operational,  it  already  provides  the  best  overall  time  trans¬ 
fer  capabilities  in  existence.  Time  transfer,  using  a  Time  Transfer 
Unit  (TTU)  designed  and  built  for  the  U.S.  Naval  Observatory  (USNO)  by 
STI,  has  been  demonstrated  to  be  consistently  better  than  50  nanoseconds 
when  done  so  with  GPS  satellites  with  good  clocks. 

Ultimately,  GPS  will  allow  continuous  global  determination  of  time  when 
the  complement  of  satellites  in  the  system  provides  the  appropriate 
coverage.  (Only  one  satellite  in  view  is  required  for  time  transfer.) 
At  present,  global  determination  is  possible,  but  not  continuously. 
Currently,  the  GPS  program  plan  is  to  have  an  18  satellite  constella¬ 
tion4,  which  would  provide  global  satellite  visibility  of  4-8  satel¬ 
lites  above  5°  elevation  (7  satellites  28.7%  of  the  time).5  The  origi¬ 
nal  planned  constellation  of  24  satellites  would  have  provided  visibil¬ 
ity  of  6-11  satellites  above  5°  elevation.  A  possible  near-term  con¬ 
stellation  of  six  satellites  will  provide  one  satellite  time  transfer 
coverage  ranging  from  approximately  16.5  to  20  hours  per  day,  depending 
upon  location.  As  it  turns  out,  one  of  the  worst  time  coverages  is  the 
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continental  United  States  (and  the  Indian  Ocean)  because  the  constella¬ 
tion  was  designed  to  provide  a  clustering  of  satellites  for  testing  at 
Yuma,  Arizona.5  Examples  of  satellite  coverage  for  those  six  satel¬ 
lites  are  presented  in  Figure  1. 

The  Time  Transfer  Systems,  both  old  and  new,  operate  on  only  the  GPS 
LI  C/A  (Clear/Acquisition)  code  at  1575.42  MHz.  They  do  not  operate  on 
the  L2  frequency  (1227.60  MHz)  because  the  C/A  code  will  usually  not  be 
available  on  that  frequency.  The  reasons  for  operating  only  on  the  C/A 
code  are  for  simplicity  and  because,  in  the  future,  the  P-code  will  not 
be  available  to  all  users.  It  will  be  obvious  from  later  discussions 
that  operating  on  the  P-code  would  only  improve  the  time  transfer 
accuracy  by  about  30-35  nanoseconds  (one  sigma)  when  operating  with 
large  ionospheric  propogation  delays,  to  very  little  improvement  when 
the  delays  are  small.  For  most  applications,  this  improved  accuracy  is 
not  required,  and  for  some  users  that  need  it,  special  purpose  P-code 
time  transfer  systems  can  be  developed. 

The  Time  Transfer  Systems  also  operate  only  from  known  surveyed  (and 
stationary)  locations.  In  future  systems,  position  determination  with 
limited  motion  is  anticipated  as  an  option.  Position  determination 
does  degrade  the  time  transfer  accuracy  because  of  Geometric  Dilution 
of  Precision  (GDOP)  and  Time  Dilution  of  Precision  (TDOP)  effects  (see 
Reference  4  for  definitions  of  GDOP  and  TDOP). 

The  USNO  TTU  is  described  in  detail  in  References  7  and  8.  This  unit 
was  delivered  to  the  USNO  late  in  1979  and  has  been  operating  since 
mid- 1980  very  well.9  A  summary  of  results  obtained  from  this  unit  will 
be  presented  later  in  this  paper.  It  has  been  instrumental  in  the 
determination  of  the  long-term  performance  of  the  GPS  frequency  stan¬ 
dards  in  orbit,  as  well  as  the  performance  of  GPS  time. 

The  USNO  TTU,  because  it  was  the  first  Time  Transfer  System  built,  is  a 
large  and  not  so  portable  unit.  Because  of  that,  STI  has  developed  a 
new  TTS,  the  TTS  502,  that  has  similar  performance  characteristics,  but 
is  relatively  small,  even  to  the  point  of  being  portable  (a  near  future 
option).  The  unit  is  shown  in  Figure  2.  Details  of  this  new  system 
are  presented  later  in  this  paper. 

Also  presented  in  this  paper  are  the  techniques  for  accomplishing  the 
time  transfer,  a  time  transfer  error  analysis,  a  description  of  various 
applications  of  the  TTS  and  some  future  considerations  for  the  use  of 
GPS  for  time  transfer. 

TIME  TRANSFER  TECHNIQUE 

For  users  with  known  locations,  only  one  satellite  signal  is  required 
for  time  transfer  purposes.  The  time  transfer  technique  employed  is 
illustrated  in  Figure  3  which  shows  the  timing  relationships  between 
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the  system  (GPS)  time,  satellite  time,  and  the  user  s  time  when  an 

GPS 

epoch  transmitted  from  the  satellite  (at  GPS  time  Tt  ),  arrives  at 

GPS 

the  user's  location  (at  GPS  time  T .  ).  Time  transfer  is  accomplished 

A  U 

by  computing  the  user  clock  error,  AT^  ,  with  respect  to  system  time, 

when  an  epoch  is  received.  GPS  satellites  transmit  continuous  signals 
with  readily  identified  subframe  epochs  every  six  seconds.  The  trans- 
SV 

mission  time,  Tr  ,  is  determined  by  an  on-board  atomic  standard  which 

SV 

will,  in  general,  differ  by  some  amount,  AT,  from  system  time. 


When  the  epoch  arrives  at  the  station,  the  transit  time  is  measured  as 
observed  by  the  user.  This  measurement,  called  pseudorange  (PR),  is, 
in  essence,  the  time  difference  between  the  user  time  at  epoch  arrival 

and  the  satellite  time  at  epoch  transmission,  TySV>  i.e., 


PR  =  T 


U 


SV 


A  'T 

In  terms  of  system  time,  the  pseudorange  can  be  expressed  as 


PR  -  TaGPS  -  TtGPS 


SV  .  ,T  U 

A't  +aTa 


(1) 


(2) 


The  term  T 


GPS 


T- 


GPS 


A  'T 


is  the  "true"  transit  time  (with  respect  to 

system  time)  representing  the  true  time  range,  R,  between  the  satellite 
and  the  station  except  for  a  propagation  delay  r: 


GPS  T  GPS  _ 
A  1 1 


(3) 


The  user  clock  error  is  readily  obtained  from  (2)  and  (3)  as 

ATaU  -  PR  +  ATTSV  -  R  +  i  (4) 

The  propagation  delay  includes  the  ionospheric  and  tropospheric  propa¬ 
gation  time  delays  and  a  receiver  equipment  bias. 

A  raw  time  transfer  is  performed  every  six  seconds  at  the  reception  of 
the  satellite  signal  epoch  (subframe  epoch)  by  the  following 
procedure: 

SV 

o  Deriving  satellite  (epoch)  transmission  time,  IA  ,  from  the 
Z-count  contained  in  the  broadcast  data  subframe  (inferred 
after  initial  synchronization). 
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SV 

o  Computing  satellite  clock  error,  ATt  ,  and  system  transmis- 
GPS 

sion  time,  ,  using  clock  correction  parameters  contained 

in  the  data  frame. 

GPS 

o  Computing  satellite  position  at  system  time  TT  using  the 
satellite's  ephemeris  contained  in  the  data  frame. 

o  With  the  known  user  location,  estimating  the  propagation  delay 
x  using  (1)  ionospheric  correction  parameters  contained  in  the 
data  frame,  (2)  a  simple  tropospheric  correction  model,  and 
(3)  receiver  equipment  bias  calibration  data  provided  by  the 
user  during  system  initialization. 


o  Computing  the  satel 1 ite-to-station  range  R,  taking  into  account 
the  effect  of  earth  rotation  during  signal  propagation. 


o  Collecting  a  pseudorange  measurement,  PR,  when  the  epoch 

arrives,  and  finally,  computing  the  user  clock  time  error 

according  to  equation  (4). 

These  raw  user  clock  time  errors  are  then  collected  in  a  rotating  buf¬ 
fer  so  that  they  can  be  smoothed  to  reduce  the  effect  of  the  receiver 

noise  and  quantization  errors.  The  smoothing  is  accomplished  by 
applying  a  least  squares  fit  on  the  values  in  the  buffer.  This 
smoothed  error  is  then  subtracted  from  the  time  of  the  epoch  arrival 
to  provide  the  GPS  time  of  arrival 


GPS  „  T  U 
A  A 


(5) 


where  AT^  is  the  smoothed  user  clock  time  error  evaluated  at  user 

time  T.U  .  However,  the  time  transfer  is  accomplished  by  providing 

h  1) 
the  user  with  a  time  pulse  that  is  either  coincident  with  T^  ,  along 

with  the  correction,  or  with  a  time  pulse  that  has  been  corrected  with 

U  GPS  UTC 

the  past  best  estimate  of  AT.  ,  and  thus  corrected  to  T.  or  T. 

.  H  UTC 

The  corrected  pulse  is  an  option  of  the  TTS.  To  correct  to  T^  ,  the 

epoch  time  of  arrival  in  Universal  Coordinated  Time  (UTC),  a  known 
difference  between  UTC  and  GPS  time  is  applied.  This  known  differ¬ 
ence  is  presently  supplied  by  the  user.  In  the  future  it  will  be 
supplied  in  the  GPS  Navigation  Message8. 


THE  TTS  502 


A  block  diagram  of  the  TTS  502  is  shown  in  Figure  4.  It  is  comprised 
of  an  STI  Time  Transfer  Receiver  Model  5026,  an  Omni  byte  Motorola-based 
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MC68000  microcomputer  and  software,  antenna,  preamplifier  and  a  dis¬ 
play  station.  Also,  options  to  the  basic  TTS-502  are  illustrated. 
These  options  are: 

o  001  Precision  internal  5  MHz  crystal  oscillator 

o  002  1  pps  (pul se-per-second)  output  corrected  to  GPS  or  UTC 
time 

o  003  RS-232  interface  for  data  output  to  external  peripherals 

o  004  GPIB  interface  for  data  output  to  external  peripherals 

o  005  Desk  Top  Cabinet  Enclosure  (not  shown) 

Other  options  will  be  added  in  the  future  and  will  be  based  on  future 
user  requirements.  For  example,  for  portability,  an  option  for  a 
portable  chassis  and  a  portable  display  and  control  terminal  will  be 
offered. 

Timing  Sources 

The  IIS's  flexible  relationship  to  external  or  internal  frequency 
standards,  oscillators,  or  digital  clocks  is  illustrated  in  Figure  5, 
resulting  in  3  time-source  operating  modes. 

The  TTS-502  can  be  controlled  with  a  3-position  switch  on  the  rear 
panel  to  operate  in  one  of  the  following  three  modes: 

Mode  1:  Internal  5  MHz  and  Internal  1  pps  Mode 

(Internal  5  MHz  with  Option  001  only) 

In  this  mode,  an  external  1  pps  signal  is  not  required.  With  Option 
001,  the  TTS-502  includes  a  precision  5  MHz  quartz  crystal  oscillator 
generating  an  internal  5  MHz  signal  from  which  all  the  required  fre¬ 
quency  references  and  timing  pulses  are  generated  when  operating  in 
Mode  1.  The  GPS  time  transfer  is  made  with  respect  to  an  internally 
derived  1  pps  signal.  A  TTS-502  with  Option  001  can  also  operate  in 
Mode  2  or  Mode  3. 

Mode  2:  External  5  MHz  and  Internal  1  pps  Mode 

In  this  mode,  a  user-supplied  external  5  MHz  signal  is  used  to  derive 
all  of  the  required  frequencies  and  timing  pulses.  The  TTS-502  uses 
the  5  MHz  input  signal  to  internally  derive  a  1  pps  signal  for  refer¬ 
encing  the  GPS  time  transfer. 
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Mode  3:  External  5  MHz  and  External  1  pps  Mode 

In  this  mode,  a  user-supplied  external  5  MHz  signal  and  a  user-supplied 
1  pps  are  input  to  the  TTS-502.  The  GPS  time  transfer  is  made  with 
respect  to  the  externally  supplied  1  pps  signal. 

In  all  of  the  above  operating  modes,  the  5  MHz  signal  is  passed  through 
and  available  as  an  output  at  the  rear  panel.  The  1  pps  used  to  refer¬ 
ence  the  GPS  time  transfer  (internally  derived  in  Modes  1  and  2,  exter¬ 
nally  provided  in  Mode  3)  is  also  available  at  the  rear  panel  with  the 
basic  system.  With  Option  002,  this  pulse  is  time-shifted  to  corre¬ 
spond  to  GPS  or  UTC  time. 

Preamplifier/Antenna 

The  preamplifier  and  antenna,  which  are  included  in  the  TTS-502  system, 
are  off-the-shelf  items.  The  preamplifier  is  an  Avantek  AM1664  modi¬ 
fied  to  accept  power  via  the  RF  cable  to  the  receiver  and  high  power 
input  protection  (Avantek  M1664N103).  This  preamplifier  is  tuned  to 
the  LI  frequency  with  a  minimum  of  50  dB  gain,  and  a  noise  figure  of 
3  dB  and  a  bandwidth  of  10  MHz.  This  will  insure  a  receiver  system 
noise  figure  of  less  than  4  dB,  even  for  installations  with  very  long 
preamp 1  if ier -to-receiver  cable  lengths.  Its  size  is  approximately 
8  inches  by  3  inches  by  2  inches,  including  connectors. 

The  antenna  is  an  omni-directional  antenna.  It  is  right-hand  circular 
polarized  and  has  greater  than  -2  dBIC  gain  above  10°  elevation  angle 
and  greater  than  -3  dBIC  gain  above  5°  elevation  angle  with  hemispher¬ 
ical  coverage  (measured  on  a  ground  plane). 

Receiver/Processor 


A  block  diagram  of  the  Receiver/Processor  subsystem  of  the  TTS-502  is 
shown  in  Figure  6.  This  subsystem  is  the  portion  of  the  TTS  that  is 
housed  in  the  8-3/4-inch  chassis  shown  in  Figure  2  (which  includes  the 
Option  001  oscillator,  if  provided).  The  receiver  has  its  baseband 
processing  and  control  resident  in  firmware  in  a  microprocessor.  The 
receiver  hardware  consists  of  a  downconverter ,  correlator,  code  gener¬ 
ator,  code  and  carrier  NCO's  (Number  Controlled  Oscillators),  fre¬ 
quency  synthesizer  and  timer  and  a  115  volts,  60  cycle,  (both  ±10%) 
power  supply  which  also  supplies  DC  power  to  the  preamplifier.  The 
receiver  operates  on  the  LI,  C/A  code  signals  only,  and  in  conjunction 
with  the  microprocessor,  acquires  the  satellite  signals,  tracks  the 
code  and  carrier  of  the  acquired  signal,  demodulates  the  navigation 
data,  performs  parity  checking  on  the  data,  measures  pseudorange  and 
doppler  and  provides  the  data  and  measurements,  upon  request,  to  the 
MC68000  microprocessor.  That  control  will  occur  at  a  maximum  rate  of 
once  per  second,  either  as  an  acquisition  command  or  as  a  measurement 
request. 


394 


TM8A 


The  receiver  accepts  the  LI  C/A  RF  signal  from  the  preamplifier.  Its 
sensitivity  is  better  than  132  dBm  (at  the  preamplifier)  and  it  has  a 
dynamic  range  of  greater  than  20  dB,  with  a  spurious  response  greater 
than  60  dB  at  130  MHz  from  the  carrier.  Its  3  dB  IF  bandwidth  is  25 
MHz.  Its  pseudorange  measurement  resolution  is  48.9  nanoseconds,  which, 
in  the  time  transfer  algorithms,  is  smoothable  down  to  a  one  sigma  of 
0.9  nanoseconds. 

The  MC68000  microprocessor ,  in  addition  to  controlling  the  receiver, 
contains  all  of  the  time  transfer  software  (firmware).  Its  basic  duty 
cycle  for  computing  time  transfer  values  is  once  per  six  seconds. 

Some  of  the  basic  features  of  this  processing  are  described  below. 

Time  Transfer  Software  Processing 

The  TTS  software  package  resident  in  the  MC68000  microprocessor  is 
written  primarily  in  a  FORTRAN  language.  However,  the  entire  software 
system  will  be  compiled  and  “burned"  into  Programmable  Read  Only  Mem¬ 
ories  (PROM's)  on  the  microprocessor  card.  In  addition  to  volatile 
Random  Access  Memory  (RAM)  available  for  processing,  nonvolatile  RAM  is 
used  to  store  initialization  parameters  to  circumvent  reentering  those 
parameters  whenever  power  is  lost  or  removed  and  then  restored. 

The  software  routines  are  designed  to  perform  a  variety  of  functions: 
operator  input  handling,  receiver  signal  acquisition  control,  satel¬ 
lite  data  collection  and  processing,  scheduling  and  schedule  control, 
time  transfer  algorithm  execution,  data  smoothing,  data  statistical 
analysis,  data  display,  data  output,  etc. 

The  primary  purpose  of  the  software  processing  is  to  provide  the  user 
the  flexibility  of  exercising  various  modes  of  operation  to  suit  his 
requirements.  Most  important,  the  software  processing  provides  an 
automatic  mode  of  operation  in  which  visible  satellites  are  scheduled 
to  be  tracked  under  software  control,  permitting  continuous  time 
transfer  operation.  Once  this  mode  is  initiated,  no  further  operator 
intervention  is  required,  and  the  TTS  is  operated  in  a  so-called  "do 
forever"  loop. 

The  TTS  with  its  application  software  processing  is  designed  primarily 
for  the  automatic  controlling  of  the  receiver  to  track  a  sequence  of 
visible  satellites  based  on  a  24-hour  tracking  schedule,  in  support  of 
continuous  time  transfer  operation.  fhe  TTS  provides  two  modes  of 
control  for  setting  up  this  schedule. 

Under  the  full  automatic  mode  of  control,  a  24-hour  satellite  tracking 
schedule  is  generated  internally  by  the  software  based  on  a  stored 
almanac  and  known  user  location.  The  criterion  used  for  generating  a 
schedule  is  such  that  every  satellite  chosen  by  the  operator  will  be 
tracked  at  least  once  every  day.  This  schedule  is  automatically 
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revised  daily  to  account  for  the  GPS  satellite  constellation  preces¬ 
sion.  To  override  the  full  automatic  schedule,  the  user  may  exercise 
the  semi-automatic  mode  of  control  in  which  the  user  is  allowed  to  set 
up  a  24-hour  schedule  using  any  criterion  he  may  choose. 

In  either  mode,  once  a  schedule  is  set  up,  it  will  be  maintained  by 
the  program  and,  at  the  beginning  of  each  tracking  interval,  the 
receiver  will  be  automatically  reset  with  a  new  satellite  identifica¬ 
tion  number  and  initial  doppler  estimate  computed  using  stored  almanac 
data.  Since  almanac  data  for  all  satellites  are  updated  occasionally 
by  the  GPS  Master  Control  Station,  the  stored  almanac  data  to  be  used 
by  the  system  are  continuously  and  automatically  refreshed  once  the 
system  is  in  operation. 

Starting  with  a  new  satellite  acquisition  command,  the  time  transfer 
operation  proceeds  through  three  phases  of  operation.  In  the  first 
phase, the  signal  acquisition  phase,  the  receiver  will  acquire  and  track 
the  selected  satellite.  During  this  phase,  the  receiver  acquisition 
process  is  monitored  by  the  program  until  the  signal  is  successfully 
acquired  and  subframe  synchronization  is  achieved. In  the  next  phase, 
the  initial  data  acquisition  phase,  satellite  data  subframes  demodulated 
by  the  receiver  are  input  and  processed  every  six  seconds  until  a 
complete  set  of  error-free  data  is  collected.  Normally,  these  two 
phases  will  take  much  less  than  one  to  two  minutes,  depending  upon 
whether  time  had  been  previously  established.  The  final  phase,  time 
transfer  solution  phase,  will  last  for  the  rest  of  the  scheduled  time. 
This  phase  consists  of  a  number  of  time  transfer  cycles,  each  cycle 
occuring  at  6-second  subframe  epochs. 

At  the  beginning  of  each  cycle,  the  processor  inputs  a  300-bit  data 
subframe,  receiver  status  information,  and  measured  pseudorange  and 
doppler  from  the  receiver.  Pseudorange  and  doppler  measurements  are 
taken  every  second  and  combined  at  the  end  of  six  seconds  to  provide  a 
smoothed  measurement  for  the  time  transfer  computations.  The  receiver 
status  information  is  used  for  monitoring  the  receiver  performance, 
and  for  accessing  the  validity  of  the  measured  pseudorange.  The  pur¬ 
pose  of  the  data  subframe  is  threefold:  first,  to  derive  the  satel¬ 
lite  time  of  transmission  from  the  subframe  Z-count;  second,  to  refresh 
satellite  navigation  and  almanac  data;  and  finally  to  check  if  the 
navigation  data  is  being  updated  by  the  satellite.  If  so,  a  new  set 
of  satellite  ephemeris  data  will  be  collected  to  keep  the  microproces¬ 
sor  data  base  current. 

The  time  transfer  algorithms  are  then  applied  to  estimate  user  clock 
time  error,  to  enter  that  error  into  the  time  offset  smoothing  process, 
to  display  data  in  a  variety  of  forms,  based  on  user's  selected  options, 
and  to  output  data  to  the  optional  output  ports.  Typical  displays 
show  the  station  clock  time  error,  the  time  of  day  (in  GPS  or  UTC  time), 


396 


TM8A 


date  (in  Modified  Julian  Date  Number),  age  of  data,  receiver  status, 
satellite  identification  number,  and  elevation  and  azimuth  angles. 

Besides  the  two  major  modes  of  operation  described  above,  the  ITS 
software  processing  also  provides  additional  modes  of  operation  which 
allow  the  user  to  initialize  the  data  base,  collect  an  initial  set  of 
almanac  data,  to  obtain  satellite  constellation  times  of  visibility, 
and  to  exercise  the  manual  mode  of  control  in  which  a  particular 
satellite  of  interest  can  be  tracked  until  terminated  or  until  it  is 
no  longer  in  view. 

TIME  TRANSFER  ERROR  ANALYSIS 

Various  sources  of  error  that  could  affect  the  accuracy  of  the  time 
transfer  to  varying  degrees  are  listed  in  Table  I  and  are  discussed 
bel ow. 

Satellite  Group  Delay  and  Clock  Errors 

Normally,  satellite  group  delay,  which  is  caused  primarily  by  delays 
in  satellite  signal  paths,  are  indistinguishable  from  the  satellite's 
clock  time  offset.  Therefore,  they  are  included  in  the  GPS  Control 
Segment's  estimate  of  that  clock  offset.  Elowever,  that  estimate  is 
based  on  dual  frequency  (LI  and  L2)  measurements  of  pseudorange, 
absorbing  any  group  delay  differential  between  the  LI  and  L2  signal 
paths  within  the  satellite.  This  differential  has  no  effect  on  two- 
frequency  users.  However,  since  the  TTS  has  an  LI  only  receiver,  that 
differential,  multiplied  by  a  factor  of  1.546,  is  not  accounted  for  in 
the  polynomial  clock  correction  terms  of  the  Navigation  Message. 11 
However,  it  is  accounted  for  in  the  TGD  term  included  in  that  message. 
The  error  in  that  term  is  affected,  however,  by  the  Control  Segment's 
ability  to  measure  it  through  the  ionosphere  at  times  of  relatively 
small  ionospheric  delays.  However,  that  error,  along  with  perturba¬ 
tions  in  the  absolute  group  delay  in  the  satellite,  is  expected  to  be 
insignificant  compared  to  the  satellite's  random  clock  drift  described 
below.  Therefore,  they  can  be  neglected. 

The  satellite  clock  errors  are  basically  the  error  in  the  satellite's 
polynomial  clock  correction  terms  of  the  Navigation  Message.  That 
error  is  caused  by  three  sources:  the  satellite's  random  clock  drift, 
the  group  delay  described  above,  and  the  Control  Segment's  inability 
to  estimate  and  predict  the  clock  drift  exactly.  These  errors  are 
very  much  related,  so  it  makes  no  sense  to  try  and  differentiate  them. 
Over  a  period  of  time,  however,  the  random  clock  drift  will  normally 
dominate  if  the  satellite's  clock  is  reasonably  stable.  (In  other 
words,  a  clock  is  one  that  meets  specification  -  a  nonanomal ous  satel¬ 
lite.)  That  assumption  is  made  here,  since  that  is  the  case  for  all 
but  the  first  two  satellites  launched.  In  fact,  the  most  recently 
launched  satellites  have  very  stable  clocks. 
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Since  these  clocks  do  vary  in  stability,  it  makes  more  sense  to  dis¬ 
cuss  the  specified  stability  rather  than  the  actual  stability.  The 
numbers  in  Table  1  reflect  those  specifications12’13.  For  the  Phase 
I  satellites,  the  clock  errors  were  specified  for  only  two  hours  after 
upload  of  the  satellite,  obviously  to  cover  specific  testing  periods. 
However,  since  the  TTS  could  be  used  anywhere,  that  error  budget  has 
been  extended  to  24  hours  here,  using  the  clock  Allan  variance  charac¬ 
teristics  provided  in  Appendix  III  of  Reference  13  and  the  time  drift 
models  of  Reference  14.  Since  there  are  two  types  of  frequency  stan¬ 
dards  operating  in  the  Phase  I  satellite  (Rubidium  and  Cesium),  a 
range  is  given  for  the  clock  error  budget  of  25.5-108  nanoseconds  (one 
sigma)  for  24  hours  after  upload  (25.5  for  Cesium,  108  for  Rubidium). 
These  are  based  on  the  equations: 


a2(t)  = 


I 0-2Of  +  -t  ) 

1U  ^  LUPl_0ADj 


+  1.44  X  10- 24 ( t- t(j p lqad ) 2  seconds2  (6) 

for  the  Rubidium  standard,  and 

a2(t)  -  2.5  X  10-21(t-tupL0AD) 

+  5.76  X  10"26(t-typPQAp)2  seconds2  (7) 

for  the  Cesium  standard. 


Although  the  drift  of  the  Rubidium  standard  causes  the  TTS  error  budget 
to  exceed  the  100  nanoseconds  advertised,  the  standards  that  are  opera¬ 
tional  have  been  performing  much  better  than  specified. 

For  the  operational  GPS  system,  the  Operational  Control  Segment  (0CS) 
is  simply  specified  to  upload  the  satellites  as  often  as  required  to 
maintain  the  combined  clock  and  ephemeris  errors  to  within  20  nanosec¬ 
onds  (6  meters),  one  sigma. 

The  nature  of  these  clock  errors  are  basically  bias-like  over  the 
smoothing  interval  of  the  TTS  (240  seconds,  maximum). 

Satellite  Ephemeris  Prediction  Errors 

These  errors  are  primarily  the  Control  Segment's  inability  to  predict 
the  satellite's  ephemeris  (position  versus  time)  exactly  plus  any 
perturbations  that  are  unpredictable.  These  errors,  along  the  line- 
of-sight  to  the  user,  are  budgeted  to  be  12  nanoseconds  (3.6  meters), 
one  sigma  for  the  Phase  I  system  for  24  hours  after  upload,  and  are 
combined  with  the  clock  errors  as  described  above  for  the  operational 
system.  Actually,  the  errors  are  somewhat  negatively  correlated  with 
the  clock  errors  and  tend  to  cancel  somewhat  over  short  periods  of 


398 


TM8A 


time  after  upload.  Therefore,  it.  makes  more  sense  to  combine  the  error 
budget  as  it  is  for  the  operational  system. 

As  for  the  clock  errors,  the  ephemeris  errors  are  basically  bias-like 
over  the  smoothing  interval  of  the  ITS. 

Ionospheric/Tropospheric  Delays/Multipath  Errors 

These  errors  are  obviously  independent  of  each  other;  however,  they  are 
worse  at  low  elevation  angle  tracking  and  minimized  at  higher  elevation 
angles.  The  multipath  errors  can  be  controlled  with  good  installation 
practices.  They  can  also  have  a  relatively  random  component  that  could 
be  lumped  in  with  the  receiver  noise  errors.  The  tropospheric  delay  is 
corrected  with  a  simple  model. 

In  any  event,  the  ionospheric  delay  correction  error  will  usually 
dominate,  since  the  TTS  has  no  capability  of  measuring  pseudorange  at 
two  frequencies.  It  must  rely  on  the  ionospheric  correction  model 
provided  in  the  Navigation  Message.10’16  In  fact,  under  normal  situa¬ 
tions,  the  ionospheric  delay  correction  error  will  dominate  the  TTS 
performance. 

Reference  15  treats  this  correction  error  in  detail.  In  summary,  the 
ionospheric  delay  error  is  caused  by  the  integrated  electron  content 
along  the  ray  path  between  the  satellite  and  the  user.  The  delay 
effect  is  dependent  on  both  the  character  of  the  ionosphere  at  the 
zenith  and  the  elevation  angle  to  the  satellite.  The  character  at 
zenith  is  highly  dependent  on  geometric  latitude  of  the  user  and  the 
time  of  day,  and  is  not  very  predictable.  Figure  7  shows  typical 
measurements  of  ionospheric  delay  for  an  L-band  signal  (near  LI) 
received  at  vertical  incidence.16  The  mean  ionospheric  delay  at  night¬ 
time  is  on  the  order  of  ten  nanoseconds.  During  the  daytime  the  mean 
delay  increases  to  as  high  as  fifty  nanoseconds.  At  low  elevation 
angles  the  delay  can  be  up  to  three  times  the  values  given  above  (30- 
150  nanoseconds).  Although  these  delays  are  partially  corrected  with 
the  Navigation  Message  model,  that  model  will  normally  be  in  error  by 
about  50  percent  of  the  delay  (one  sigma).15  Therefore,  as  a  "ballpark" 
estimate,  it  is  assumed  that  the  ionospheric  delay  correction  error, 
combined  with  the  tropospheric  correction  and  multipath  error,  ranges 
between  5-40  nanoseconds  (one  sigma),  depending  upon  many  variables. 
This  error  is  the  most  important  error  source  of  the  TTS  time  transfer 
error. 

Receiver  Noise  (and  Random  Multipath)  Errors 

Receiver  noise  is  dominated  by  the  thermal  noise  effects  on  the  per¬ 
formance  of  the  receiver's  code  loop  (neglecting  unintentional  jamming, 
of  course).  Since  the  TTS  receiver's  code  loop  is  aided  by  its  carrier 
loop,  and  because  pseudorange  measurements  are  relatively  infrequent 
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(once  per  second),  its  loop  bandwidth  is  quite  small,  reducing  the  raw 
measurement  receiver  noise  error  to  15.5  nanoseconds,  one  sigma. 
Smoothing  to  one-second  measurements  reduces  this  error  to  6.3  nano¬ 
seconds,  one  sigma.  Also,  this  error  is  random  in  nature;  therefore, 
since  the  ITS  software  processing  smooths  the  raw  time  transfer  results, 
this  6.3  nanoseconds  can  be  further  reduced  to  about  1.0  nanoseconds, 
one  sigma  (40  sample  smoothing). 

Pseudorange  Quantization  Errors 

The  least  significant  bit  of  the  TTS  pseudorange  measurements  is  worth 
48.9  nanoseconds  (l/20th  of  a  C/A  code  chip).  This  is  reduced  by  the 
square  root  of  12  to  a  one  sigma  value  of  14.1  nanoseconds,  since  it 
is  a  uniformly  distributed  error  between  ±24.4  nanoseconds.  (The  bias 
is  a  time  error  that  is  part  of  the  receiver's  calibration  correction, 
primarily  because  pseudorange,  as  measured,  is  always  positive).  As 
was  the  case  for  the  receiver  noise  errors,  these  quantization  errors 
are  further  reduced  in  the  TTS  software  processing  because  they  are 
smoothed,  reducing  the  14.1  nanoseconds  down  to  about  5.8  nanoseconds, 
one  sigma  for  the  smoothed  6-second  measurement  and  down  to  0.9 
nanoseconds,  one  sigma,  in  the  time  transfer  smoothing  (40  sample 
smoothi ng) . 

User  Location  Estimation  and  Receiver  Bias 

The  TTS  makes  use  of  the  user  coordinate  in  the  estimation  of  satel¬ 
lite- to- user  range,  and  therefore  must  be  known  accurately.  The  error 
budget  for  this  estimation  depends  on  the  surveying  technique  used  to 
determine  the  coordinates.  If  a  GPS  Geoceiver  is  used  for  the  survey, 
the  GPS  position  can  be  derived  quite  accurately,  to  within  about  1-2 
meters17’18  (~B  nanoseconds).  Otherwise,  the  location  error  could 
be  somewhat  larger,  and  budgeted  to  be  up  to  about  5  meters  05  nano¬ 
seconds),  one  sigma.  This  error  is  bias- I  ike,  and  therefore  cannot  be 
smoothed  over  the  TTS  smoothing  intervals. 

The  TTS  receiver  bias  from  the  antenna  to  the  input  (or  output)  1  pps, 
is  calibrated  prior  to  TTS  delivery.  The  error  and  subsequent  drift 
in  that  bias  is  well  within  the  location  error  budget  given  above.  Of 
course,  any  cable  length  changes  require  a  new  bias  input. 

Total  (RSS)  Time  Transfer  Error  Budget 

Table  I  lists  the  various  individual  error  budget  that  makes  up  the 
total  TTS  time  transfer  error  budget.  The  RSS  totals  are  given  as 
ranges,  consistent  with  the  ranges  given  for  the  individual  budgets. 
Also,  the  smoothed  error  budget  is  given  versus  the  raw  error  budget, 
assuming  40  sample  smoothing  (6  seconds  per  sample).  For  the  Phase  I 
GPS  error  budget,  two  totals  are  given  -  one  for  the  Rubidium  satel¬ 
lite  frequency  standards  and  one  for  the  Cesium  satellite  frequency 
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standards.  All  budgets  are  well  within  the  advertised  budget  of  100 
nanoseconds  for  the  TTS,  except  for  worst  case  Rubidium  frequency 
standard  drifts,  which  to  date  have  not  been  exhibited. 

USNO  TTU  RESULTS 

Acceptance  Test  Results 

The  acceptance  tests  of  the  USNO  Time  Transfer  Unit  were  conducted  for 
five  days  in  November  1979,  as  part  of  the  unit  acceptance  tests.  The 
following  is  an  excerpt  from  a  paper  by  Dr.  Kenneth  Putkovich8,  USNO 
representative  at  the  time  of  the  acceptance  tests. 

"Initial  tests  of  the  time  transfer  capability  of  the  Time  Transfer 
Unit  (TTU)  were  carried  out  as  part  of  the  unit  acceptance  tests.  A 
pair  of  portable  atomic  clocks  was  carried  to  the  MCS  (Master  Control 
Station)  at  Vandenberg  AFB  in  California.  The  ensemble  of  atomic 
clocks  which  constitute  the  GPS  master  clock  were  measured  against  the 
portable  clocks  with  particular  attention  to  the  clock  serving  as 
reference  for  the  Vandenberg  Monitor  Site.  Pertinent  system  delays  in 
the  monitor  receiver  were  also  measured  and  verified  with  site  person¬ 
nel.  The  portable  clocks  were  then  transported  to  the  STI  facility  in 
Sunnyvale,  where  a  series  of  time  transfers  were  made  using  the  port¬ 
able  clocks  as  reference  for  the  TTU.  The  clocks  were  then  returned 
to  Vandenberg  (to  establish  a  baseline  for  GPS  time)  and  then  taken 
back  to  Sunnyvale  for  a  final  series  of  measurements.  The  results  of 
this  initial  series  of  measurements  are  presented  in  Figure  4  (Figure 
8  in  this  paper).  As  can  be  seen  from  the  plot,  time  transfers  with 
a  precision  of  better  than  ±50  nanoseconds  were  achieved." 

After  the  portable  atomic  clocks  were  shipped  back  to  USNO,  additional 
testing  was  performed,  this  time  using  a  Cesium  standard  which  was 
calibrated  against  the  atomic  clocks.  These  tests  also  produced 
similar  results. 

Subsequent  Testing  and  GPS  Time  Performance  Monitoring8 ’ 19 

Subsequent  tests  performed  by  the  USNO  involved  the  verification  of 
GPS  Time  at  the  GPS  Master  Monitor  Station  via  portable  clocks  and  the 
acquisition  and  tracking  of  as  many  passes  of  the  satellites  currently 
in  operation  as  possible.  These  tests  resulted  in  the  same  level  of 
performance  as  the  initial  acceptance  testing,  but  revealed  what 
appeared  to  be  several  discontinuities  in  GPS  Time.  An  investigation 
showed  the  cause  of  these  steps  to  be  GPS  master  clock  changes  and 
failures  in  GPS  Monitor  Stations.  Since  then,  due  to  a  coordinated 
effort  between  USNO  and  the  GPS  program  office,  an  improvement  has 
been  made  as  the  magnitude  and  frequency  of  the  discontinuities  has 
decreased.  More  details  of  GPS  Time  monitoring  are  given  in  Reference 
19,  which  covers  a  period  of  time  up  through  about  the  end  of  1980. 
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The  TTU  has  also  been  used  to  monitor  the  performance  of  the  frequency 
standards  in  the  GPS  satellites.  Those  performances  are  also  pre¬ 
sented  in  Reference  19  over  the  same  time  frame  and  have  also  been 
presented  in  terms  of  Allan  variance  numbers  in  Reference  20.  That 
performance  is  monitored  by  "backing  out"  the  satellite  clock  correc¬ 
tion  polynomial  derived  from  the  GPS  Navigation  Message11,  which 
basically  "uncorrects"  the  satellite  clock  time  from  GPS  Time  to  the 
time  of  the  satellite's  subframe  epoch  transmission.  In  a  sense,  the 
accuracy  in  this  TTS  estimate  of  satellite  time  is  better  than  that  of 
GPS  Time  because  it  is  not  corrupted  by  the  prediction  errors  in  the 
clock  correction  polynomial,  which  is  evident  from  results  presented 
in  Reference  19.  However,  this  estimate  is  of  little  value  to  the 
normal  TTS  user,  unless  he  is  primarily  interested  in  monitoring 
satellite  clock  performance,  with  one  exception.  Since  the  USNO 
publishes  the  difference  between  their  Master  Clock  and  each  satel¬ 
lite's  clock,  a  user  can  perform  a  time  transfer  to  UTC  via  a  satel¬ 
lite  clock  instead  of  via  GPS  Time.  The  published  difference  of  a 
good  satellite  clock  is  more  accurately  predictable  by  extrapolation 
than  that  of  GPS  Time  to  the  user's  time  of  transfer.  However,  if  the 
user  does  not  extrapolate  and  uses  data  common  to  the  USNO  after  the 
fact,  it  makes  no  difference  because  the  clock  correction  polynomial 
prediction  errors  cancel.  (In  fact,  in  a  common  view  time  transfer 
performed  while  in  communication  with  the  USNO,  all  common  errors  such 
as  satellite  clock  errors,  ephemeris  prediction  errors,  and  part  of 
the  ionospheric  delay  correction  errors  cancel,  resulting  in  a  more 
accurate  time  transfer.  This  has  been  suggested  and  demonstrated  by 
the  National  Bureau  of  Standards.21’22). 

USNO  GPS  Time  Service 

Data  from  the  GPS  satellites  are  recovered  daily  by  the  USNO  and  are 
made  available  through  the  USNO  Time  Service  Automated  Data  Service 
(ADS)  via  standard  dial-up  telephone  line,  using  a  modem  and  terminal. 
(See  Reference  19.)  This  service  was  used  to  obtain  more  recent  data 
than  that  presented  in  Reference  19  for  a  satellite  that  has  had  a 
Cesium  beam  standard  operating  for  some  time  (SV#9).  The  data  was 
retrieved  for  a  period  of  190  days  starting  on  January  1,  1981.  The 
results  provided  by  the  Time  Service  are  plotted  in  Figure  9  for  both 
the  difference  between  GPS  Time  and  the  USNO  Master  Clock  and  the 
difference  between  SV#9‘s  clock  and  the  USNO  Master  Clock.  The  fol¬ 
lowing  polynomials  (three  point  derived)  were  removed  from  the  data 
before  plotting: 

GPS  Time:  -35.811  ps  -  1.3352X10-12  s/s  X  t  (8) 

+  (2. 81436X10-1 -/86400)s/s2  X  t2 

SV#9  Time:  346,428  ns  +  3.6651X10-13  s/s  X  t  (9) 

+  (6. 04051X10-16/86400)  s/s2  X  t2 
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where  t  is  in  seconds  since  1  January.  These  coefficients  are  equiva¬ 
lent  to  drift  values  of: 

GPS  Time:  Af/f  =  -1. 3352X1Q-12 

D  =  5. 62872X10- 1 3/day 

SV#9  Time:  Af/f  =  3.6651XX0-13 

D  =  1. 2081X10- ls/day 

It  is  evident  from  these  plots  that  the  satellite's  clock  is  better 
than  the  GPS  clock.  This  should  be  expected  since  the  GPS  clock  is 
much  older  than  the  satellite's  clock.  The  fact  is  that  both  clocks 
are  exhibiting  normal  "flicker11  characteristics.  The  anomalous 
results  that  occurred  around  day  130  are  due  to  transient  conditions 
in  the  GPS  system  after  a  "Master"  receiver  failure.  Time  in  the 
master  GPS  clock  was  reinitialized.23 

The  results  of  Figure  9  are  consistent  with  the  results  presented  in 
Reference  19  for  a  previous  period  of  time. 

TIME  TRANSFER  APPLICATIONS 

The  Time  Transfer  System  can  be  employed  in  a  variety  of  applications. 
As  a  stand-alone  system  it  can  provide  an  absolute  time  reference  for 
users  within  GPS.  By  using  the  data  provided  by  USNO's  Time  Services, 
GPS  Time  (or  any  of  the  SV  times)  can  be  translated  to  UTC.  More 
stable  timing  can  be  achieved  by  operating  the  TTS  with  an  external 
Cesium  or  Rubidium  standard  to  bridge  periods  of  nonvisibility  to 
satellites  in  the  current  GPS  system.  Intermittent  accurate  time 
transfer  can  be  achieved  with  the  optional  internal  crystal  oscilla¬ 
tor,  with  accuracies  on  the  order  of  microseconds  during  periods  of 
nonvisibi 1 ity. 

The  TTS  can  also  be  used  as  a  calibration  device  to  provide  time 
alignment  of  other  standards  in  the  user's  timing  network. 

For  a  timing  network  in  which  only  relative  time  is  required,  the 
so-called  "common  mode-common  view"  technique  of  time  transfer  can  be 
employed  to  provide  even  better  accuracy.21  In  this  mode,  a  highly 
stable  TTS  is  used  as  the  master  clock  (such  as  the  one  at  USNO)  and 
another  TTSat  a  remote  location  will  be  simultaneously  scheduled  to 
track  an  identical  satellite  that  is  visible  from  both  TTS's.  When 
the  time  offsets  obtained  from  these  two  TTS's  are  compared,  better 
(relative)  accuracy  will  be  achieved  due  to  the  cancellation  or  reduc¬ 
tion  of  common  sources  of  error,  e.g.,  satellite  clock  and  ephemeris 
error,  and  some  of  the  atmospheric  time  delay  error. 
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As  an  example,  Figure  10_  shows  the  times  that  two  TTS's  located  in 
Washington,  D.C.  and  Paris,  France  may  both  see  a  particular  satel¬ 
lite.  Note  that,  even  with  the  six-satellite  constellation,  the  daily 
common  view  period  can  be  as  much  as  15  hours. 

This  technique  is  similar  to  that  employed  in  TV  line-10  transfers, 
where  simultaneous,  common  view  measurements  against  a  stable  trans¬ 
mitter  yield  measurements  with  ten-nanosecond  uncertainty.  Intercon¬ 
tinental  time  transfer  at  ten  nanoseconds  should  be  possible  with  GPS 
TTS's. 

FUTURE  CONSIDERATIONS 

In  the  near  future,  the  TTS  502  will  be  available  in  a  portable  config¬ 
uration.  The  receiver/processor  chassis  will  be  packaged  as  a  portable 
unit.  The  preamplifier  and  antenna  are  already  quite  portable.  Port¬ 
able  terminals  are  also  available  on  the  market  or  may  already  be 
available  at  remote  sites.  And  the  TTS  does  not  need  batteries.  It 
can  be  plugged  into  any  115  VAC  wall  socket.  Initialization  parameters 
can  be  stored  in  nonvolatile  memory  (or  PROM)  at  a  laboratory  or  depot 
site,  and  the  TTS  can  be  shipped  unattended  to  a  remote  site  as  a 
calibration  device.  The  only  starting  parameter  that  is  needed  is  an 
approximate  time-of-day  and  day-of-year,  which  could  conceivably  be 
entered  with  other  means  besides  a  terminal  (such  as  a  set  of  thumb¬ 
wheels,  a  start  button,  and  an  LED  readout),  eliminating  the  need  for  a 
terminal. 

As  the  number  of  TTS's  increase,  they  will  become  smaller  than  "Flying 
Clocks,"  and  competitive  in  price.  They  are  already  lighter  (no 
batteries),  and  much  less  expensive  to  maintain  and  transport  (again, 
no  batteries).  ‘  '  ~ 

As  GPS  matures  and  more  satellites  become  available,  it  is  also  con¬ 
ceivable  that  the  TTS's  will  also  replace  frequency  standards  in  the 
field.  Over  the  short  term  they  are  not  quite  as  accurate,  but  over 
the  long  term  they  will  be  nearly  as  accurate  as  UTC  itself  (±100 
nanoseconds  or  less).  And,  they  will  never  need  calibrating.  As  with 
the  flying  clocks,  the  TTS  will  also  eventually  become  competitive  in 
price  with  accurate  frequency  standards. 
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TABLE  I 

TIME  TRANSFER  ERROR  BUDGET 

PHASE  I  GPS  SPECIFIED  OCS  SPECIFIED 


ONE  SIGMA  ERROR  BUDGET12 
(nanoseconds) 

ONE  SIGMA  ERROR  BUDGET 
(nanoseconds) 

SV  GROUP  DELAY 

AND  CLOCK 

9  (for  2  hrs) 

25. 5-108  (for  24  hrs) 

20* 

SV  EPHEMERIS 

12  (for  24  hrs) 

IONOSPHERIC/ 

TROPOSPHERIC 

DELAY/MULTIPATH 

5-40** 

5-40** 

RECEIVER  NOISE 
(RAW/SMOOTHED) 

6. 3/1.0 

6. 3/1.0 

PSEUDORANGE 

QUANTIZATION 

(RAW/SMOOTHED) 

5.8/0. 9 

5. 8/0. 9 

USER  LOCATION 
ESTIMATION  AND 
RECEIVER  BIAS 

5-15 

5-15 

TOTAL  (RSS) 

(18- 117)/ (17- 117)*** **** 

(23~50)/ (21-47) 

(RAW/SMOOTHED)  (18-52)/(17~51)**** 


*  BETWEEN  SUCCESSIVE  UPLOADS13 

**  ELEVATION  ANGLE,  LATITUDE  AND  TIME  OF  DAY  DEPENDENT 

***  RUBIDIUM  FREQUENCY  STANDARD  IN  SATELLITE 

****  CESIUM  FREQUENCY  STANDARD  IN  SATELLITE 
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FIGURE  3  TIMING  RELATIONSHIPS 
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FIGURE  4  TIME  TRANSFER  SYSTEM  502 
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FIGURE  5  TTS-502  TIME  SOURCE  OPERATION  MODES 


FIGURE  6  TIME  TRANSFER  RECEIVER/PROCESSOR  MODEL  5026  BLOCK  DIAGRAM 
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TIME  OF  OAT  (III)  TIME  OF  DAT  (UT)  TIME  OF  HAY  ((IT) 

(HOURS)  (HOURS)  (HOURS) 


FIGURE  7  MEAN  IONOSPHERIC  DELAY  AND  ENVELOPE  OF  DELAY  VARIATION  VS.  TIME 
OF  DAY  DURING  -MARCH ,1958-  SATELLITE  AT  ZENITH  f=1.6  GHz 
(FROM  REFERENCE  16) 
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FIGURE  8  INTIAL  TIME  TRANSFER  RESULTS 
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FIGURE  10  COMMON-VIEW  TIME  BETWEEN  WASHINGTON , DC  AND  PARIS, FRANCE 
ON  2  OCT  1980 


QUESTIONS  AND  ANSWERS 


MR.  KELLOGG,  Lockheed 

In  collecting  the  data  and  evaluating  it,  I  noticed  you  have  gone 
through  the  U.S.  Naval  Observatory  time  comparison  with  UTC;  is 
that  true  or  that  is  just  a  possibility? 

MR.  HUA: 

That's  true. 

MR.  KELLOGG: 

Do  you  have  any  data  which  would  permit  evaluating  whether  we 
should  have  great  confidence  in  the  relativity  corrections  which 
have  been  built  in  to  the  standard  on  board  the  satellite? 

MR.  HUA: 

I  do  not  have  any  answer.  I  do  not  know  much  about  that  to  answer 
your  question  about  relativity. 

MR.  ALLAN: 

I  think  I  can  answer  that,  and  the  corrections,  I  believe,  are 
correct,  and  I  think  you  can  have  great  confidence  in  those. 

MR.  KELLOGG: 

Thank  you. 
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